Trains in blueprints Building trains again and again might be a daunting task. Especially when you start making a lot of mining outposts, artillery/supply trains with filtered cargo wagon slots etc. So I decided that we should extend blueprints to work with trains as well. The first condition was, that trains are only selected when you explicitly allow it in the checkbox, so they don't get in your way when building rail setups. Checking the button allows the train that was there to be put into the blueprint (similar to the way tiles work). For the sake of simplicity, we decided that once there is any rail in the blueprint, the train in it will be always buildable (as a ghost obviously), even if there are not rails to support the train at the moment. The train ghost will simply stay there and won't be buildable until rails are placed under it in a way so it can be placed. If I remove the rails from the blueprint, I get a second type of rail blueprint. In this case, all the parts of need to have rails to support it, this is mainly needed as without rails, there is no rail grid forced, so we should make sure, the train ghost won't be created in some wrong position. The small touch here is, that the blueprint also contains the schedule. With little-bit of improvisation, I can optimize the mine building a lot in the late game. I create a blueprint of mine train station. The stop will be called " Mine X". Both of the trains in the blueprint will have the " Mine X" -> " Smelting" schedule setup. Once I build the blueprint, I just rename the " Mine X" to whatever I want (" Mine 12" for example), and the train schedules are updated as well, so I'm almost ready to go. The last tweak I'm considering is to allow blueprints to contain the fuel insertion info similar to how they contain the module insertion info for assembling machines now.

In FFF-241 we discussed how the game delivers information to the player in a number of confused ways; Blinking arrows and circles, chat messages on the bottom left corner of the screen, objectives in the top left, orange modal boxes bubbles on top of the player, and so on. These problems are exacerbated on high resolution monitors, where the information becomes even further spread apart. We have tried a few ways to unify this information, but much of it was required to be in the world space, or needed to have a link between the screen space and the world space. The common solution to this is to have the GUI 'point' to an entity in the game world, but we wanted something more interesting.

The many lessons learned from testing the new tutorial We have already pointed out, that we are trying to make a new campaign (FFF-245), and part of it is the core beginning, the NPE/tutorial. The tutorial is one of the very critical parts of the game, as if the first 15 minutes of a game feels shitty, there is big chance that the player will not play any further. I had this experience in many games myself. So the challenge could be articulated like this: "The current tutorial is okay, but can we make it great?" The approach in the current tutorial is to feed the player with the basic knowledge of how to control the basics of the game (the first mission and the start of the second mission) in the fastest way possible. The player is even given descriptive info like this, to diminish the chance of not understanding how the basic entities work. After few steps in the 2nd level, the player can start exploring his first self-feeding loop (make iron to make more iron). The tools used to this is mainly: The message dialog that stops the game and explains the player various things. Minimization of the amount of things the player can interact with to absolute minimum, so he can't start doing other things before the basics are clear. The possible drawbacks: The constant interruptions can get really annoying (typically around 22 message dialogs before the player starts to play relatively freely in the 2nd level). The possibility, that the player will mindlessly follow the step-by step tasks without understanding it, so he can become really lost later on, and the tutorial basically wouldn't help him to understand things. So the question is: Can we make a tutorial that makes these problems go away?, and alternatively, How big are these problems actually? The current direction of the new tutorial attempt is to never use the message dialogs, so the player can learn the game more fluently, and to leave way more things to explore, as learning things yourself has a better chance of success than force-feeding generally. We made a few tests of the new approach with a few people, the main takeaway, is that nothing is for free, and this approach created new drawbacks. If the player doesn't figure out something basic, it can be very frustrating for him to figure out what is going on when not moving forward for a long time. It might be possible, that some things are just not fun to learn by exploration, and it is more comfortable if they are force fed to you. I would compare this to a friend explaining you how to play a game for 5 minutes compared to 2 hours of trial and error. There are more possible outcomes from this, and we shall see how different tweaks of both strategies work in the testings. It might be interesting if you mentioned your experience with the tutorial in the comment section as well.

Hi Factorians, This is Dominik, and my first FFF post ever! I will use this opportunity to talk to you about the exciting subject of pipes. Yeah, I know, right? Spring came and with it Twinsen, saying "Pipes suck. Two people already tried to fix it and failed, who wants to be next?", and I’m like "Hey, that’s just pipes, you just make a simple simulation, simple AF. I’m in." The conditions were even quite lenient: Fluids get where they should. They should act in a predictable manner, with reasonable splitting/joining in junctions. Fluids can travel instantly, if need be. Respect the pipe throughput limitations. Flow can be viewed on the pipes. Don’t do f**** up stuff like running in a circle indefinitely, sloshing back and forth endlessly etc. Should be faster/more UPS efficient. I am mostly working on the new GUIs, but still, the fact that summer is over and pipes are not done, kinda shows how simple fixing them is. Very naive I was.

Scan-codes vs Key-codes (posila) While migrating from Allegro to SDL, HanziQ and Jiri replaced the keystroke handling from using key-codes to scan-codes. Before you start jumping with joy, you’ll probably wonder: What is that and why should I care? Well, funny you should ask. You probably won’t care, unless you live outside of USA and/or you use a non-US keyboard layout. In short, key-code is a key identifier dependant on the symbol the key will output when pressed, scan-code is a key identifier based on the physical location of a key. So for example players with French keyboard layout (AZERTY) have to jump to the control options after launching the game for the first time, and remap movement from WASD to ZQSD, in order to be able to move their character without hurting their hand. In 0.17, the controls will map to the correct keys by default, regardless of your layout, and stay mapped to those physical keys even if you for some reason change your keyboard layout while the game is running. The disadvantage is, most of the non-US layouts didn’t end up with completely broken controls, so people kept playing with them and got used to them. So they’ll need to get used to the layout the game was originally designed with, or manually configure controls back to what they are used to. But wait, there is a catch... A few weeks ago we have announced new construction tools, which are by default bound to quite universal shortcuts (Ctrl+C for copy, Ctrl+X for cut and Ctrl+Z for undo). Bilka pointed out that the German keyboard has Z swapped with Y (as does the Czech one, but developers often don't use it) and undo incorrectly defaults to Ctrl+Y instead. To fix these kind of shortcuts we determine the appropriate default scan-codes at start-up, so that undo is always Ctrl+Z, regardless of your layout, but the action will stay bound to those keys if you change keyboard layout at runtime, which is hopefully a reasonable compromise. We might do it for other controls too (it feels natural for M to always be the default key to open the map, and T to open the technology screen), but there is another catch. It is completely reasonable for player to walk north, and Ctrl+click some entities. Remember AZERTY keyboard? Player keeps Z pressed down to walk north and presses Ctrl to start control clicking. Well, I tested this and it doesn’t trigger undo, but still stops player from walking. So it is not completely destructive, rather annoying. I am not sure how or if we’ll solve this, perhaps people with these layouts that create these kind of collisions will need resolve them by changing controls options manually.

Taming the random generatorTwinsen One of the things in the large TODO list for 0.17 is giving a final polish to the map generator. There are quite a few obvious problems now in 0.16, and some less obvious ones. Here are some of the fixes and improvements (some work in progress): All combinations of settings should no longer create strange maps such as circles of cliffs. Much more predictable starting area resources that don't overlap each-other and are not covered by water. The resource generation settings now have a much more dramatic effect (previously they had little to no effect). Increased the number of steps (small, medium, big, etc) for each setting from 5 to 9 for even more customization. The starting area will always contain water, most often a lake close to the spawn position. Since the algorithm for generating ores was pretty much completely rewritten, there are many small improvements. Now for the less obvious problem: unpredictability. I saw quite a few people complain with vague comments like "the map generator sucks". So I often asked them what the problem is in detail. Some were complaining about the above problems, some did not understand what the settings do, and some had problems finding a "good map". I saw quite a few players click "regenerate" like crazy until they got a map with fat patches in the starting area, big oil patch and also uranium, complaining that it's too hard to find a "good map". Due to the randomness we seem to have set the expectation for "good map" a bit too high. Oil and uranium were never intended to be in the starting area, but due to the randomness of the generator they sometimes were there. Also sometimes maps were so wild that you would start off either swimming in resources or desperately looking for another iron patch. It would be simple to just say "that's just RNG, deal with it", but blaming poor game experience on RNG is just bad design. So what we did is: The starting area contains only iron, copper, coal and stone, in very predictable amounts. Uranium and oil are explicitly excluded from the starting area. Starting area resources are usually in one ore patch each (depending on settings). The starting area patches are usually close together. The starting area size setting no longer affects resource placement, it just has a fixed size. Outside the starting area, the regular algorithm "kicks in" so you can still get quite wild results, but they are far enough that it averages out. I believe this is a good balance where you can still have different experiences depending on your luck, but your starting experience is much more predictable and does not leave you with the feeling that you got screwed over by the map generator. We definitely don't want the map generator to be extremely flat and predictable. Opinions on the subject are quite wild too, with people having different expectations of what a good map should look like, so we try to only make changes based on actual problems. This might seem a bit controversial so we can add an option that disables this whole starting area logic, for purists. We plan some small tweaks coming to biters also (a tiny bit more biters close to the starting area), small tweaks to terrain, cliffs, water generation and possibly some new features to make the generated trees and decoratives look better. Most of these problems including the obvious and apparently simple ones were not that easy to solve. It's hard to make random generators do what you want, so TOGoS will explain what it took to actually get it done.

With most of the team away for Gamescom or vacation, I have the pleasure of writing a Friday Facts for you this week.

Hello, A bunch of us will be travelling to Gamescom next week as visitors, if you see anybody wearing a Factorio t-shirt, it might very well be one of us. We don't have a booth or exhibit this year, as we don't want to take any focus away from the development of the game.

Hello, we had a small Factorio 0.17 LAN party this weekend. The purpose was to try and test some of the new features and play the game properly as I haven't had time for that for quite a while. I used this opportunity to think about all the smaller or bigger decisions, features or change of plans in the context of playing the game for many hours.

Hello, we are really appreciating that the new offices have proper air conditioning...